Typically computer systems have a processor, memory, display, an input device and a printer. A computer program, called a print driver, is stored in the memory and is executed by the processor to communicate with the printer. When a new printer is attached to the computer system, typically a new print driver is also installed. Sometimes a new print driver is installed for an existing printer to fix software problems or enhance the printer's operation. Computer systems often store many different types of application programs that use the printer to print different types of documents. For example, the application programs may include a word processing program, a spreadsheet program and a drawing program.
The printing process under MICROSOFT WINDOWS™ (Registered Trademark of Microsoft Corporation) is as follows. The application translates the document to be printed into an intermediate representation with the aid of a MICROSOFT WINDOWS™ module called Graphics Device Interface (GDI). The GDI also displays graphics and text on a display. MICROSOFT WINDOWS™ instructs the print driver to translate the intermediate representation to the specific language of the printer, such as Hewlett-Packard's PCL™ (Registered Trademark of Hewlett Packard Company) and Adobe's POSTSCRIPT™ (Registered Trademark of Adobe Systems Inc.).
Printing a document tests and exercises a print driver because the driver translates from the intermediate representation to the language of the printer. The more varied the documents, the better the testing because more aspects of the print driver are tested. Using different types of applications and documents increases the likelihood that the print driver is tested properly.
When a print driver is changed or a new print driver is added, the system is tested to make sure the print driver operates properly. Traditionally, two techniques have been used to test print drivers—a manual technique and a partially automated technique. In the manual technique, the tester manually performs a series of steps to test the print driver. For example, the user opens an application, such as Microsoft WORD, and opens a document via Microsoft WORD. The user manually calls the print driver through Print Setup, sets options, such as orientation and paper size, and approves the options by hitting an OK or Apply button. The user instructs the application to print the document. The problem with the manual technique is that it is tedious, time-consuming and error-prone. Because users often forget the sequence of steps, if a problem arises, it is difficult to retrace the user's steps to identify the source of the problem.
In the partially automated technique, a programmer writes a test program that “hard codes” the names and behaviors of the applications, documents and drivers in the test program. When executed, the test program opens the application and document, sets the values of the driver options, prints the document, and closes the document and application. The problem with the partially automated technique is that adding new applications, drivers, or driver options may involve rewriting or modifying the test program. The test program is designed to test a set of specified applications using specified drivers with specified sets of options. However, the test program may not be able to test a print driver when new applications are added, when the operation of the specified driver has changed, or when options are added. In any of these cases, the test program must either be modified or rewritten. Although the test program can be designed using modular programming and common procedures to reduce the number and magnitude of modifications, the test program must still be at least modified.
In view of the foregoing, it would be desirable to provide a method and system to automatically test drivers. This method and system should allow applications, documents, drivers and driver options to be easily added, modified and deleted.